FE-1602: Restyle the Petrinaut architecture docs - #9527

Restate Starlight's palette and type scale as one flat monochrome
system, so the chrome reads as a single surface divided by hairlines
and colour is left to the things that carry meaning.

Collapsing the left panel now animates: the pane hides with
visibility rather than display, the content inset derives from the
pane width, and every box sized from it transitions on one curve.
A drag or a held arrow key already tracks its input, so the handle
marks the gesture and the transitions stand aside.

Both rails and the collapse toggle sit at 70% until the pointer or
keyboard focus reaches them, over 300ms, with the whole rail as the
hover target. prefers-reduced-transparency turns the effect off.

A 30px band under the header blurs and tints the content passing
beneath it. backdrop-filter cannot ramp on its own, so the ramp is
three stacked layers of increasing radius, each masked to a shorter
band, and each filtering what the one beneath it produced.

Blocks now sit 1.5rem apart with 2.25em above a section heading, and
body copy is 17px: Starlight defines --sl-text-body but never applies
it, so the size had to be set here.

The band ran both to 30px, which hid the blur: its strongest layers
sit at the top, which is exactly where the tint is opaque. The tint
keeps its 30px and the blur now runs to 60px, so below the tint there
is a stretch where content is blurred and still visible.

Radii go up with it, 4px to 16px.

The three layers now differ by height rather than by mask alone. All
are anchored under the header and run to a different depth: 60px at
1px of blur, 40px at 2px, 20px at 4px. They overlap towards the
header and thin out to one at the bottom, so the tallest and weakest
is the layer that meets unblurred content.

Each fades out over its own lower half, so a layer ending reads as a
soft edge rather than a line across the page.

The band's construction moves to a shared class so the rail and the
content column build it from one set of rules.

The rail scrolls independently of the page, so its band keys off the
pane's own scrollTop and appears only once rows have gone up behind
the header. Shown unconditionally it would sit on the first row of an
unscrolled rail and dim it for nothing.

Height and opacity both come off `--pnd-nav-progress`, which the
header script writes from the rail's scrollTop, 0 to 1 over the first
60px. At rest the band has no height, so it stays off the first row of
an unscrolled rail. Nothing eases it: the value already tracks the
scroll frame by frame, and a transition would leave the band lagging
the rows it covers.

The ramp is now two layers rather than three, 60px at 1px of blur and
30px at 2px, in both places the band is used.

A held arrow key repeats about thirty times a second and each repeat wrote
to localStorage, which writes synchronously. The width a keyboard gesture
reaches is now kept in hand and written when the gesture ends on keyup or
blur, the same as a drag already did.

The bands took their progress from a number the header script wrote on
every scroll, so a page restored to a scroll position painted once
without them and then with them. Measured against first contentful
paint, that write lands 4ms late on an idle machine and 181ms late under
a 6x CPU throttle, which is the flash: about eleven frames of a page
whose bands arrive after the content.

A scroll-driven animation resolves the same progress from layout, on the
first frame, and takes the scroll listeners with it. The rail's bands
reach its scroller through a named timeline, since they are drawn in the
header rather than inside the rail, and the foot band runs reversed over
the last stretch of the scroll, which is how what is left below the fold
falls out of a timeline that only counts distance travelled. Its
ResizeObserver goes too: an opened group changes the timeline's own
extent.

Firefox has shipped neither half, so the script stays as the fallback
there, gated on the same condition the stylesheet tests. The ramp is a
CSS token now, read by the script rather than repeated in it.

…'s inset

The rail now rests at 52.5% and the collapse button at 37.5%, three
quarters of what each sat at. The right-hand panel and the theme select
are left where they were.

This costs contrast, and no colour buys it back: composited, rail text
lands at 3.1:1 against the 4.5:1 body text owes, and the button's icon
at 2.5:1 dark and 2.3:1 light against 3:1. At 52.5% over a white page
even pure black reaches only 4.35:1, and at 37.5% only 2.6:1, so the
lever is the resting opacity rather than the grey. Both still come to
full strength on hover and on keyboard focus, and reduced-transparency
turns the fade off. The note in the stylesheet records the measured
figures rather than the ones it used to claim.

The button also moves 4px left, to sit 16px from the viewport's left
edge, which is what the 64px header leaves above a 32px button. The
title wrapper clips its overflow, so it is extended by the same 4px and
given it back as padding: the clip boundary travels with the button and
the logo beside it does not move.

Splitting `--pnd-rail-idle-opacity` out so the rail could rest lower than
the right-hand panel left it out of the `prefers-reduced-transparency`
rule, which still lifted only the two tokens that existed before. Every
other piece of chrome went to full strength and the rail stayed at
52.5%, so the preference missed the one element that recedes furthest,
and at that opacity its text is the 3.1:1 the stylesheet already records.

Nothing tied a new token to that rule, so the built-CSS check now ties
them: it collects every `--pnd-*-idle-opacity` declared and fails on any
the rule does not lift. Run against the branch before the fix it named
`--pnd-rail-idle-opacity` on its own.

Measured with the media feature emulated: rail, right panel, toggle and
theme select all resolve to 1 with the preference set, and to 0.525,
0.7, 0.375 and 0.7 without it.